Fix culture-dependent number conversion and large JSON integer literals - #225

Problem

Two bugs in how the scripting language handles numbers:

1. Culture-dependent text-to-number conversion. ShellText and ShellIdentifier parsed numbers with the current culture. On a de-DE system, . is a group separator, so $t = "1.5"; echo $($t * 2.0) printed 30 and $($t - 0.5) printed 14.5, silently producing wrong values.
2. Large integers in JSON literals were rejected. JSON object and array literals reused the Int32-only integer parsing, so mkitem {"id":"1","ts":1727600000000} failed with Invalid number format. Millisecond timestamps and other 64-bit identifiers are common in Cosmos DB documents.

Changes

Culture-invariant conversion (Use invariant numeric shell conversions)

• Numeric parsing in ShellText, ShellIdentifier, ShellJson, ShellObject, and the remaining ExpressionParser integer paths uses NumberStyles with CultureInfo.InvariantCulture, matching how the lexer already parses decimal literals.

Large JSON integers (Accept large JSON integer literals)

• In JSON object and array value positions, integer-form tokens outside Int32, including a leading unary -, become JSON number constants. The literal digits are preserved exactly, including values beyond 2^53. For example, {"n":9007199254740993} is stored without precision loss or a .0 suffix.
• Plain integer literals outside JSON keep the documented 0..2147483647 limit.
• Arithmetic on such properties follows the documented rule that larger JSON integers use double.

docs/programming.md documents both behaviors.

Tests

• CultureInvariantConversionTests run under de-DE: text and identifier conversions, end-to-end expression evaluation, and rejection of "1,5".
• ExpressionTests cover large positive and negative integers in objects, arrays, and nested objects, values just above Int32.MaxValue and beyond 2^53, arithmetic on such properties, and the unchanged error for plain 2147483648.